The present invention relates to block pattern detection circuitry, and, more particularly, to such circuitry providing for improved error handling in a streaming tape drive system.
Streaming tape drives are bulk data storage and retrieval devices which are used, for example, in conjunction with a host computer. Basic performance criterion include the amount of information that can be stored on a tape medium and the rate at which information can be written onto and read from the tape. In general, performance is improved by increasing the density, i.e., the amount of information stored per unit length of tape, and the speed at which the tape travels across read and write heads of the streaming tape drive system.
However, increases in speed and density constrain the tolerances available to the tape drive system and the tape itself. Errors become more frequent as the tolerance constraints become more difficult to meet and maintain. Generally, these errors occur as bits of information as read turn out to be different than they were intended to have been written. Since the value of information is greatly diminished when its integrity is uncertain, error handling ability emerges as an additional important performance specification for high-performance streaming tape drive systems.
As a prelude to a discussion on error handling, consideration is given to the form in which information is stored on the tape media. Basically, information is stored as magnetic flux levels in a magnetic media. To achieve the desired higher speeds and densities, the information can be stored in parallel tracks. For example, each bit of a nine-bit "word" can be assigned to a respective track of a nine-track tape so that all bits of the "word" are simultaneously available during retrieval. The tape is then configured as a series of nine-bit words.
Since the "user" data supplied and requested by the host computer is generally unintelligible to the I streaming tape drive system, little error handling could be performed if only user data were stored on the tape. Therefore, a streaming tape drive system typically adds information intelligible to it, providing the capability of evaluating the integrity of the read and write operations.
For example, the user data can be made more manageable by formatting it into blocks separated by "gaps". The user data generally includes data proper which is recorded within data blocks, and file end markers, which are recorded as tape marks. Since formatting conventions can vary, a flexible tape drive system can apply identification marks during write operations identifying which formatting conventions, e.g., phase encoded (PE ID), double-density phase encoded (DPE ID), group code recorded (GCR ID), apply to a given tape.
Each of these standard formats includes a scheme for encoding user data which permits errors to be detected and, if possible, corrected. For example, a nine-track tape drive permits the system to add an error-detection parity bit to each eight-bit word of user data. The more complex group code recording rearranges sets of seven user bytes into sets of ten bytes with error correction codes, with additional bytes added for residuals and cyclical redundancy check bytes.
Furthermore, user end-of-file marks, which can be a single character, are converted to tape marks which comprise a predetermined pattern repeated for many consecutive flux spaces. For example, in GCR format, a tape mark consists of activity in tracks 1, 2, 4, 5, 7 and 8 and erasure in tracks 3, 6 and 9, this pattern being repeated for 250 to 400 flux spaces. This conversion makes file boundaries far less vulnerable to noise than would be the case if the file boundary character were simply recorded as a one character record.
According to the format selected, preambles, postambles, and embedded marks can be added to identify block boundaries and permit synchronization across parallel data channels. For example, a preamble to a block of user data can be used by de-skew circuitry to ensure that the channels of digital data corresponding to the tracks of flux data are synchronized with respect to each other so that the individual bits of a word are processed as such, and not as bits of preceding or succeeding words.
Other types of system data can be written along with the foregoing. For example, automatic read amplification (ARA) bursts can be used to automatically set gain levels within the tape drive system. Such ARA bursts can be identified as such by ARA ID marks.
As an illustration of how system data can enhance error handling, once the format is determined from an ID mark, the error codes can be used to flag errors in otherwise unintelligible user data. Additionally, the preambles to data blocks can be used for synchronization, as indicated above. When a gap is detected following a block before a postamble is detected, this can indicate that a full-width drop-out has occurred within the data block. Generally, the included system data generates a set of acceptable recognizable patterns, deviations from which can be used to flag errors.
The system data is applied by the tape drive system during write operations by a write formatter section of a write subsystem. The system data is then checked by the read subsystem during a read operation, or during a write operation in verify mode. In either case, it is the read subsystem which performs the checking; the read head can be positioned upstream of the write head so that information is read after it is written to verify that the system data conforms to the conventions being implemented.
Of course, system data is not immune to errors, so it is important that the tape drive system be able to distinguish user data and system data, even when errors are present. However, while system data can include so much noise as to be unidentifiable, it is still distinguishable from user data by the absence of preambles and postambles.
Once an error is detected, a strategy for addressing the error must be implemented, usually in conjunction with a drive controller which controls the transfer of the tape in response to information from the read subsystem and other sources. Viable options include: correcting the error in-stream, attempting a correction by re-writing or re-reading the pertinent portion of the tape, and passing the defective data with an error flag.
During write-with-verify operations, re-writing is usually implemented even for easily correctable errors. A second error can render a correctable one-bit error uncorrectable. Therefore, correctable errors should be corrected while the original user data is available to build in tolerance for subsequent errors.
During read operations, in-stream correction is preferred where possible because it has minimal impact on the speed of operation. Errors that cannot be corrected in-stream generally result in re-tries, which are relatively time consuming. If the error remains uncorrected despite re-tries, the error can be flagged to warn the user or to initiate a shut-down or other "drastic" error procedure according to the strategy implemented.
Of course, when a re-try is necessitated, correction is not guaranteed. Re-reading cannot correct severe errors due to damaged media, for example. However, there are other problems inherent in the re-try operation itself. In order to re-try a portion of the tape, a streaming tape drive must correctly position itself so that just after it re-starts and regains operating speed it is just in front of the portion to be retried. Mis-positioning can be wasteful in that portions of tape not needing a re-try can be wastefully re-read. More seriously, positioning errors can confuse the system into treating one block as another, compounding the original error.
Much of the error-handling responsibility falls on the read subsystem which detects and identifies, system data, user data and gaps. A read system can include, by way of example, analog circuitry associated with the read head, analog-to-digital conversion means, de-skew circuitry for synchronizing data streams arranged in parallel tracks on the tape, block detect circuitry, and read/format circuitry.
Of these sections of the read subsystem, the block detect circuitry which identifies locates and verifies data block types and inter-block gaps, is central to a tape drive system's error handling. For example, a "drop-out" within a block of data can cause a gap to be erroneously detected. Conversely, noise or a "drop-in" can cause a block to be erroneously detected within a gap. Likewise data blocks tape IDs and marks can be confused with each other, or rendered incomprehensible to the system. Such errors generally require re-tries which significantly impair system throughput, or may result in an unrecoverable read error.
Once it is determined that a re-try is required, the drive controller subsystem polls various sections of the read subsystem to determine the location of the portions to be re-tried. Given the high speed and flux densities of state-of-the-art systems, the delays involved in determining positions after the drive controller acknowledges an error detection would not permit the precision in positioning required for retries.
Accordingly, the drive controller polls the read subsystem for tape positions during routine events such as the occurrence of a gap-to-block boundary. However, even with this tactic, positioning errors occur due to the delays in acknowledgement of boundary detections by the drive controller, which generally is performing multiple tasks at once.
Thus, what is needed is block detect circuitry providing for improved error handling by a streaming tape drive system. This block detect circuitry should provide more positive identification of block types to minimize unnecessary re-tries, and decrease the likelihood of an unrecoverable read error. Further, the block detect circuitry should provide block delimiter signals to provide more precise positioning when retries are required.